The Evolved Packet System (EPS) as it has been specified by the Third Generation Partnership Project (3GPP) is a PS only system (see 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” the contents of which are hereby incorporated by reference in its entirety). This means there is no CS domain and the voice calls that are supported in EPS are provided through the PS domain only. Most likely these voice calls will be Voice over Internet Protocol (VoIP) calls and the underlying call control protocol will be Session Initiation Protocol (SIP) (see RFC3261, “Session Initiation Protocol,” the contents of which are hereby incorporated by reference in its entirety) supported through the IP Multimedia Subsystem (IMS) (see 3GPP TS 23.228, “IP Multimedia Subsystem (IMS); Stage 2,” the contents of which are hereby incorporated by reference in its entirety).
However, the coverage of access technologies providing the right characteristics in order to support VoIP will be “islands” in a sea of legacy 2G/3G legacy CS access technologies, which, of course, are required to support voice calls through the CS domain. Because the availability of this next generation access technologies, such as Long Term Evolution (LTE), will not be ubiquitous as is legacy CS access, such as Global System for Mobile Communications (GSM), a mechanism for a handover from a VoIP voice call to a legacy CS system would be beneficial. This mechanism that combines the access handover with the transfer of voice from PS to CS is called Single Radio Voice Call Continuity (SRVCC) and is defined in 3GPP TS 23.216, the contents of which are hereby incorporated by reference in its entirety.
Handovers from source system (or network or base transceivers subsystem or cells) to target system (or network or base transceivers subsystem or cells) is—from the User Equipment (UE) or terminal side perspective—for a session or transaction that stays within the same domain even if the UE moves from one system to another, i.e., CS to CS handover or PS to PS handover. In other words, from the UE perspective, a CS call originated in a Universal Mobile Telecommunications System (UMTS), when handed over to a GSM system, will still be the same CS call that was initiated in the UMTS system. Similarly a PS transaction initiated in UMTS and handed over to a GSM EDGE Radio Access Network (GERAN) system will remain a transaction of the PS domain.
In 3GPP systems, there is no other case for a handover in which the source transaction is originated in one domain (such as the PS domain) and ends up in a target system working in another domain (such as the CS domain).
It should be noted that the 3GPP Release 7 Voice Call Continuity (VCC) (or dual-radio VCC) (see TS 23.206, “Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2,” the contents of which are hereby incorporated by reference in its entirety) feature that transfers voice calls between PS domains and CS domains is not a handover but, rather, a domain transfer that involves two calls (that is, the UE itself establishes a call in each of source and target domains).
Hence, SRVCC presents a unique challenge regarding how the association of the voice sessions that the UE has in place will be transferred between the PS and CS domains. Effectively, the status of the calls in the PS domain (IMS) has to be transferred to the CS domain during the SRVCC handover procedure. This is needed in order to subsequently support mid-call services (such as hold/unhold of voice sessions) when the UE moves to the CS domain, where the UE may not have the capability to signal using SIP/IMS signaling because simultaneous PS and CS connectivity is not possible due to the characteristics of the access network, e.g. in case of handing over to GSM with no Dual Transfer Mode (DTM) support.
More particularly, what identifies a CS call, in the Call Control state machines on both sides (that is, the UE and the network) is the CS Call Reference Identity. In 3GPP Non-Access Stratum (NAS), this is the Transaction Identity as defined in (see 3GPP TS 23.228). That Transaction ID identifies and relates a certain call on both the UE side and the network side regardless of which side originated that call. That Transaction ID is needed to tie and synchronize the Call Control state machines of both sides since, without that Transaction ID, neither side knows or can communicate and signal about that call.
With regard to existing solutions or attempted solutions, there have been several proposals concerning how these transaction IDs can be generated and passed between the PS and CS parts of the network and the UE in order to keep the UE and network synchronized.
These proposals (see 3GPP Temporary document: S2-087424; 3GPP Temporary document: S2-087893; and 3GPP Temporary document: S2-087713, the contents of which are hereby incorporated by reference in their entirety) rely on the UE and Service Centralization and Continuity (SCC) Application Server (AS) elements of the IMS Service Continuity architecture by first generating, and then communicating, the transaction IDs to the Mobile Switching Center Server (MSC-S) when the UE moves to the CS domain.
The main deficiency of these proposals is that the UE and SCC AS (elements of the IMS architecture—see 3GPP TS 23.237, “IP Multimedia Subsystem (IMS) Service Continuity; Stage 2,” the contents of which are hereby incorporated by reference in its entirety, and 3GPP TS 23.292) are required to generate and maintain transaction IDs for all the voice calls that the UE has in place when the UE is still in the PS domain, and these transaction IDs may never be used since the UE may never handover to the CS domain. In addition, the UE and Core Network (CN) already have transaction IDs for the ongoing voice calls in the NAS layer that the UE has in place. Those are the transaction IDs that are used by the EPS bearers to transport the voice traffic when the UE is in the PS domain. Hence the generation of transaction IDs at the IMS layer (as proposed in the prior art, see 3GPP Temporary document: S2-087424; 3GPP Temporary document: S2-087893; and 3GPP Temporary document: S2-087713) is a duplication of the same identifiers.
Thus, there is an inherent inefficiency with the current state of the art.
Another issue with the current state of the art is the added requirement that the MSC Server needs to support SIP, which is not a requirement in the current specifications 3GPP TS 23.292, “IP Multimedia Subsystem (IMS) Centralized Services; Stage 2,” the contents of which are hereby incorporated by reference in its entirety.